fix: retry fallback for rejected replies by LINE#210
Conversation
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
Disabled knowledge base sources:
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds LINE TalkException "not found" error detection ( ChangesRetry without reply relation
Estimated code review effort: 2 (Simple) | ~12 minutes Sequence Diagram(s)sequenceDiagram
participant HandleMatrixMessage
participant LINEAPI
participant shouldRetrySendWithoutReplyRelation
participant clearReplyRelation
HandleMatrixMessage->>LINEAPI: Send message with RelatedMessageID
LINEAPI-->>HandleMatrixMessage: Error (reply target not found)
HandleMatrixMessage->>shouldRetrySendWithoutReplyRelation: Check RelatedMessageID and error
shouldRetrySendWithoutReplyRelation-->>HandleMatrixMessage: true
HandleMatrixMessage->>clearReplyRelation: Clear relation fields and metadata
clearReplyRelation-->>HandleMatrixMessage: Message without relation
HandleMatrixMessage->>LINEAPI: Resend message without RelatedMessageID
LINEAPI-->>HandleMatrixMessage: Success
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
| } | ||
|
|
||
| func shouldRetrySendWithoutReplyRelation(msg *line.Message, err error) bool { | ||
| return msg != nil && msg.RelatedMessageID != "" && line.IsTalkExceptionNotFound(err) |
There was a problem hiding this comment.
Broad match on TalkException code 5: IsTalkExceptionNotFound matches any code:5 reason:"not found" TalkException — the helper's own docstring in pkg/line/errors.go:148-150 warns that callers must interpret method context. Here the only additional guard is msg.RelatedMessageID != "", so if LINE's sendMessage ever surfaces a non-reply "not found" (e.g. recipient/chat missing) on a message that also carried a reply relation, we'd strip the reply and re-send once. Today that just costs one extra doomed request plus a misleading could not find reply target log; if the second attempt were ever to succeed transiently, the reply would be silently downgraded to a non-reply message on LINE. Consider tightening either the helper (parse data.reason / method) or the guard (e.g. only retry when the error string references the reply-target field) once you have a concrete signature for the reply-not-found variant.
No description provided.